[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign fabriziopandini for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

I manually modified the file. Looks like I shouldn't

         localhost.localdomain localhost4 localhost4.localdomain4" >>/etc/hosts
       - mkdir -p /etc/pre-kubeadm-commands
       - for script in $(find /etc/pre-kubeadm-commands/ -name '*.sh' -type f | sort);
-        do echo "Running script $script"; "$script"; done
+        do echo "Running script $script"; "$script"; done
\ No newline at end of file

cc @sbueringer @chrischdi

Looks like this does not work, there seems to still be some dependency on the loadbalancer IP in this case:

E0826 09:31:30.638835       1 leaderelection.go:332] error retrieving resource lock kube-system/plndr-cp-lock: leases.coordination.k8s.io "plndr-cp-lock" is forbidden: User "kubernetes-admin" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system"

More details:

kube-vip/kube-vip#684 (comment)

cc @sbueringer

Dumb, question, how does it work before in 1.28. Kube-vip also use the admin.conf generated by kubeadm, if kubeadm applies the rbac after, then kube-vip can't bootstrap either I assume in old k8s version?

v1.29 introduced the super-admin.conf. In v1.28 and before, the admin.conf immediately had the required permissions.

IC. so kubelet is able to talk to api through local ip, but not kubeadm. Kubeadm still talks to api through control plane ip. Is there use case that kubeadm init will be run not on the control plane node? Should it also support this mode to talk to api through localhost?

With ControlPlaneKubeletLocalMode and when referncing admin.conf for kube-vip:

The kubelet got started
The kubelet bootstraps itself using the local control-plane IP (not depending on kube-vip being up)
The admin.conf gets created
The kubelet should be able to start kube-vip now

IC. so kubelet is able to talk to api through local ip, but not kubeadm. Kubeadm still talks to api through control plane ip. Is there use case that kubeadm init will be run not on the control plane node? Should it also support this mode to talk to api through localhost?

With ControlPlaneKubeletLocalMode and when referncing admin.conf for kube-vip:

The kubelet got started
The kubelet bootstraps itself using the local control-plane IP (not depending on kube-vip being up)
The admin.conf gets created
The kubelet should be able to start kube-vip now

@neolit123 what do you think